Unit Test Results

     25 files       25 suites   11m 52s ⏱️
2 149 tests 2 093 ✔️ 55 💤 1 ❌
2 193 runs  2 137 ✔️ 55 💤 1 ❌

For more details on these failures, see this check.

Results for commit aec6a2e.

♻️ This comment has been updated with latest results.

Do you plan to finish this one?

Do you plan to finish this one?

Yes I do. But at the moment I'm stuck, because when I build equinox locally on my windows computer the build/tests pass (I have commented out the launcher fragments/features and the other tests to speed up the build).

If you use Linux, can you try if the the build succeeds on your computer?

I have RHEL and can take a look this week.

If this helps, and we think its good to test on different OS because equinox contains OS specific behaviour, we can setup a matrix build for equinox with windows/linux/mac(?) like I recently did for SWT.

If this helps, and we think its good to test on different OS because equinox contains OS specific behaviour, we can setup a matrix build for equinox with windows/linux/mac(?) like I recently did for SWT.

For this case it would at least help to check if the failure is OS specific or if some magic is happening at my computer that the tests pass.
But in general I think this would be beneficial as well.

Looks like the tests are not executed now and therefore don't fail. Furthermore there are many errors during compilation like the following in multiple modules. I wonder why the build doesn't fail because of them:

[INFO] --- tycho-compiler-plugin:3.0.0-SNAPSHOT:compile (default-compile) @ org.eclipse.equinox.ds.tests ---
[INFO] Compiling 18 source files to /home/jenkins/agent/workspace/equinox_master/bundles/org.eclipse.equinox.ds.tests/target/classes
Failed to init Classpath for jar file /home/jenkins/agent/workspace/equinox_master/bundles/org.eclipse.equinox.ds.tests/target/scr_test/tb1.jar-classes
java.nio.file.NoSuchFileException: /home/jenkins/agent/workspace/equinox_master/bundles/org.eclipse.equinox.ds.tests/target/scr_test/tb1.jar-classes
	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
	at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
	at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:149)
	at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
	at java.base/java.nio.file.Files.readAttributes(Files.java:1851)
	at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1264)
	at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:709)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:243)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:172)
	at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:186)
	at org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:201)
	at org.eclipse.jdt.internal.compiler.batch.ClasspathMultiReleaseJar.initialize(ClasspathMultiReleaseJar.java:38)
	at org.eclipse.jdt.internal.compiler.batch.FileSystem.<init>(FileSystem.java:235)
	at org.eclipse.jdt.internal.compiler.batch.Main.getLibraryAccess(Main.java:3495)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4741)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1802)
	at org.eclipse.tycho.compiler.jdt.JDTCompiler.compileInProcess(JDTCompiler.java:370)
	at org.eclipse.tycho.compiler.jdt.JDTCompiler.performCompile(JDTCompiler.java:123)
	at copied.org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:414)

I wonder why the build doesn't fail because of them

Because they only printed out, see eclipse-jdt/eclipse.jdt.core#239
I've stumbled over the code that silently ignored IO errors and added printouts because it was clear it will break messy build files.

To fail the build, you could try to set
-Dorg.eclipse.jdt.propagate_io_errors=true

I wonder why the build doesn't fail because of them

Because they only printed out, see eclipse-jdt/eclipse.jdt.core#239 I've stumbled over the code that silently ignored IO errors and added printouts because it was clear it will break messy build files.

To fail the build, you could try to set -Dorg.eclipse.jdt.propagate_io_errors=true

Thank you for the hint!
Maybe that explains the failure only on Jenkins before. So I think we should first ensure every works fine respectively fix it if not and then enable that property.

Do you plan to rebase and finish this one?

Do you plan to rebase and finish this one?

Thanks for the heads up. I still think this would be good to have (the more tests the better).
Lets see if the different platforms-tell a difference. I'll try to continue on this in the test days.

Test Results

  141 files  + 63    141 suites  +63   38m 6s ⏱️ + 1m 4s
2 243 tests + 73  2 142 ✅ +17   56 💤 +11  0 ❌ ±0   45 🔥 + 45 
6 868 runs  +226  6 570 ✅ +65  170 💤 +33  0 ❌ ±0  128 🔥 +128 

For more details on these errors, see this check.

Results for commit 112b319. ± Comparison against base commit 49be75d.

♻️ This comment has been updated with latest results.

The tests are now running again (I configured to skip their execution when replacing pom.xml files with pom-less, just like it was before).
But the tests are still failing in the CI.
Have to investigate further...

This seems to require manual rebase now.

@HannesWell is this still of interest?

This seems to require manual rebase now.

Done.

@HannesWell is this still of interest?

Since more tests are usually always better I think it still would be good to have this.
Maybe the full build+test execution on all platforms now helps to identify the issues.